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File Transfer Protocol HOST Command for Virtual Hosts 


Abstract 


The File Transfer Protocol, as defined in RFC 959, does not provide a 
way for FTP clients and servers to differentiate between multiple DNS 
names that are registered for a single IP address. This document 
defines a new FTP command that provides a mechanism for FTP clients 
and servers to identify individual virtual hosts on an FTP server. 


Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc7151. 


Copyright Notice 


Copyright (c) 2014 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 
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1. Introduction 


It is common on the Internet for many DNS names to resolve to a 
single IP address. This practice has introduced the concept of a 
"virtual host", where a host appears to exist as an independent 
entity but, in reality, shares its physical resources with one or 
more similar hosts. 


Such an arrangement presents some problems for FTP servers, because 
an FTP server distinguishes incoming FTP connections by IP addresses 
rather than DNS names. Therefore, all DNS names that share a common 
IP address are handled by the same FTP server and share the same 
Network Virtual File System (NVFS). 


This means that different virtual hosts cannot offer different 
virtual file systems to clients, nor can they offer different 
authentication systems. Any scheme to overcome this issue needs to 
indicate not only the destination IP address but also the virtual 
hostname that is associated with the desired virtual FTP server. 
Typical user-FTP processes currently use hostnames to perform 
hostname-to-IP-address resolution and then ignore hostnames for the 
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rest of the FTP session; therefore, any mechanism to overcome this 
issue would require modifications to the user protocol interpreter 
(user-PI) and server protocol interpreter (server-PI). 


It should be noted that this same problem existed for HTTP/1.0 as 
defined in [RFC1945] and was resolved in HTTP/1.1 as defined in 
[RFC2616] through the addition of the Host request header field. The 
goal of this document is to bring a similar level of feature parity 
to FTP by introducing a new HOST command that allows user-FTP 
processes to specify which virtual host to connect to for a 
server-FTP process that is handling requests for multiple virtual 
hosts on a single IP address. 


2. Document Conventions 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


In examples, "C>" and "S>" indicate lines sent by the client and 
server, respectively. 


This document also uses notation defined in [RFC959] and [RFC1123]. 
In particular, the terms "reply", "user", "NVFS", "NVT", "file", 
"pathname", "FTP commands", "DTP", "“user-FTP process", "user-PI", 
"user-DTP", "server-FTP process", "server-PI", "server-DTP", "mode", 
"type", "control connection", "data connection", and "ASCII", are all 
used here as defined there. 


The required syntax is defined using the Augmented BNF defined in 
[RFC5234]. Some general ABNF definitions are required throughout the 
document; they will be defined in subsequent sections. 


With the increased use of virtualization technologies, there may be 
several possible definitions for the term "virtual host". This 
document follows the definition from Section 4.1.14 of [RFC3875], 
where several virtual hosts share the same IP address, and hostnames 
are used by the server-FTP process to route user-PI sessions to the 
appropriate virtual host. 


2.1. Basic Tokens 
This document imports the core definitions given in Appendix B of 
[RFC5234]. There, definitions will be found for basic ABNF elements 
like ALPHA, DIGIT, SP, etc. To that, the following term is added for 


use in this document. 


TCHAR = VCHAR / SP / HTAB ; visible plus white space 
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The VCHAR (from [RFC5234]) and TCHAR rules give basic character types 
from varying subsets of the ASCII character set for use in various 
commands and responses. 


Note that in ABNF, string literals are case insensitive. That 
convention is preserved in this document and implies that FTP 
commands and parameters that are added by this specification have 
values that can be represented in any case. That is, "HOST" is the 
same as "host", "Host", "HoSt", etc. Similarly, because domain names 
are defined to be case insensitive, "ftp.example.com" is the same as 
"Ftp.Example.Com", "fTp.eXample.cOm", etc. 


2.2. Server Replies 


Section 4.2 of [RFC959] defines the format and meaning of replies by 
the server-PI to FTP commands from the user-PI. Those reply 
conventions are used here without change. 


error-response = error-code SP *TCHAR CRLF 
error-code = ("4" / "5") 2DIGIT 


Implementers should note that the ABNF syntax used in this document 
and other FTP-related documents (but that was not used in [RFC959]) 
sometimes shows replies using the one-line format. Unless otherwise 
explicitly stated, multi-line responses are also permitted. 
Implementers should assume that, unless stated to the contrary, any 
reply to any FTP command (including QUIT) can be of the multi-line 
format described in [RFC959]. 


Throughout this document, replies will be identified by the three- 
digit code that is their first element. Thus, the term "500 reply" 
means a reply from the server-PI using the three-digit code "500". 


3. The HOST Command 


A new command, "HOST", is added to the FTP command set in order to 
allow a server-FTP process to determine to which of possibly many 
virtual hosts the client wishes to connect. If a HOST command is 
sent, it MUST be issued before the user is authenticated, as this 
will allow the authentication scheme and set of authorized users to 
be dependent upon the virtual host that is chosen. 


Server-FTP processes MUST treat a situation in which the HOST command 
is issued more than once before the user has been authenticated as 
though only the last HOST command had been sent, and return the 
appropriate reply for the last HOST command. Server-FTP processes 
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MUST treat a situation in which the HOST command is issued after the 
user has been authenticated as an erroneous sequence of commands and 
return a 503 reply. 


Servers should note that the response to the HOST command is a 
sensible time to send their "welcome" message. This allows the 
message to be personalized for any virtual hosts that are supported. 
It also allows the client to determine, via the FEAT response, the 
languages or representations supported by the server and select an 
appropriate one via the LANG command. See [RFC2640] for more 
information. 


It should be noted that user-PI implementations that were created 
before the introduction of the HOST command will not support this new 
command. A similar problem existed with the introduction of the Host 
header for HTTP in [RFC2616], and HTTP server implementations had to 
determine how best to accommodate HTTP requests from down-level 
clients that did not support the Host header. With this in mind, 
server-FTP processes will need to determine how best to accommodate 
FTP requests from down-level FTP clients that do not support the HOST 
command, but those considerations are outside the scope of this 
document. 


3.1. Syntax of the HOST Command 


The HOST command is defined as follows. Note that [RFC3986] remains 
the normative specification for the syntactic form of IPv4 and IPv6 
address literals, in order to ensure identical presentation in ‘ftp’ 
URI hostname parts and in the protocol element specified here. 


host-command = "HOST" SP hostname CRLF 

hostname = domain / IP-literal 

domain = sub-domain *("." sub-domain) 
sub-domain = let-dig [ldh-str] 

let-dig = ALPHA / DIGIT 

ldh-str = *( ALPHA / DIGIT / "-" ) let-dig 
IP-literal = ( "[" IPv6address "]" ) / IPv4address 
IPv6address = <see [RFC3986] Section 3.2.2> 
IPv4address = <see [RFC3986] Section 3.2.2> 


host-response = host-ok / error-response 
host-ok = "220" [ SP *TCHAR ] CRLF 
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The "hostname" rule is a restricted form of the "host" rule specified 
in [RFC3986]. Details of the additional restrictions imposed by this 
document are given in the discussion of the syntax that occurs later 
in this section; they aim at simplifying implementations by only 
allowing what currently is specified precisely and in use on the 
Internet. 


As with all FTP commands, the "HOST" command word is case independent 
and can be specified in any character case desired. 


The "hostname" (given as a parameter) specifies the virtual host to 
which access is desired. This SHOULD be the same hostname that was 
used to obtain the IP address to which the FTP control connection was 
made, after any client conversions have been completed that convert 
an abbreviated or local alias to a complete (fully qualified) domain 
name, but before resolving a DNS alias (owner of a CNAME resource 
record) to its canonical name. 


Internationalization of domain names is only supported through the 
use of Internationalized Domain Names for Applications (IDNA) 
"A-labels" for <sub-domain> as described in [RFC5890]. For example, 
the following HOST command specifies an internationalized 

domain name: 


HOST xn--elafmkfd.com 


If the user was given an IPv4 or IPv6 literal address, and 
consequently was not required to derive the literal address from a 
hostname, the client MAY send the HOST command with the IPv4 or IPv6 
literal address as specified to it. While it may seem 
counterintuitive to specify a literal address by using the HOST 
command after the client has already connected to the server using a 
literal address, this should be expected behavior because a user-FTP 
process should not be required to differentiate between a fully 
qualified domain name and an IPv4 or IPv6 network literal address. 
That being said, if the IPv4 or IPv6 literal address specified by the 
client does not match the literal address for the server, the server 
MUST respond with a 504 reply to indicate that the IPv4 or IPv6 
literal address is not valid. 


When the hostname parameter contains a literal address, square 
brackets are expected to disambiguate IPv6é address syntax from port 
numbers syntax. Therefore, if the literal address is an IPv6 
address, the IPv6é address is required to be enclosed in square 
brackets (after eliminating any syntax that might also -- but is not 
required to -- be enclosed in brackets, and from which the server 
deduced that a literal address had been specified). For example, the 
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following examples MAY be sent if the client had been instructed to 
connect to "192.0.2.1", "2001:db8::c000:201", or "::192.0.2.1", 
respectively, and IPv6 syntax is preferred: 


HOST 192.0.2.1 
HOST [2001:db8::c000:201] 
HOST [::192.0.2.1] 


The client MUST NOT send the port number as part of the HOST command, 
even when the client has been instructed to connect to a non-standard 
port. The reason for this requirement is that the user-PI will have 
established a connection to the server-PI before the HOST command is 
sent; therefore, specifying a different port with the HOST command 
has no meaning. For example, the server-PI MUST respond with a 501 
reply if the client sends a HOST command with syntax like either of 
the following examples: 


HOST 192.0.2.1:2112 
HOST [2001:db8::c000:201]:2112 


The hostname parameter is otherwise to be treated as a fully 
qualified domain name or relative name as those terms are defined in 
Section 3.1 of [RFC1034]. This implies that the name is to be 
treated as a case-independent string, meaning that uppercase ASCII 
characters are to be treated as equivalent to their corresponding 


lowercase ASCII characters but otherwise preserved as given. It also 
implies some limits on the length of the parameter and of the 
components that create its internal structure. Those limits are not 


altered in any way here. 


Neither [RFC1034] nor [RFC1035] imposes any other restrictions upon 


what kinds of names can be stored in the DNS. This specification, 
however, only allows the use of names that can be inferred from the 
ABNF grammar given for the "hostname". Similarly, this specification 


restricts address literals to the IPv4 and IPv6 address families well 
established on the Internet. 


3.2. HOST Command Semantics 


Upon receiving the HOST command, before authenticating the user-PI, a 
server-FTP process SHOULD validate that the hostname given represents 
a valid virtual host for that server and, if it is valid, establish 
the appropriate environment for that virtual host. The resultant 
actions needed to create that environment are not specified here and 
may range from doing nothing at all to performing a simple change of 
working directory, changing authentication schemes and/or username 
and password lists, or making much more elaborate state changes -- 
such as creating isolated environments for each FTP session. 
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Sees 


Het 


The 220 reply code for the HOST command is the same as the code that 
is used in the initial "welcome" message that is sent after the 
connection is established. 


If the hostname specified would normally be acceptable, but is 
temporarily unavailable, the server-FTP process SHOULD respond to the 
HOST command with a 421 reply and close the connection. 


Example: 


The server-FTP process is shutting down, so the server-FTP process 
responds to the HOST command with a 421 reply and closes the 
connection. In this scenario, the 421 reply informs the client it 
can retry at another time. 


If the hostname specified is unknown at the server, or if the server 
is otherwise unwilling to treat the particular connection as a 
connection to the hostname specified, the server SHOULD respond with 
a 504 reply. 


Examples: 


The particular virtual host that was specified by the HOST command 
is disabled at the server. The server responds with a 504 reply 
and keeps the connection open in order to allow the user-PI an 
opportunity to specify another virtual host with a subsequent HOST 
command. 


Alternatively, the server-FTP process might choose to route all 
connections with unknown hostnames to a different virtual host so 
that no connection attempts will result in failed connections. 
This design would be implementation specific and outside the scope 
of this specification. 


1. REIN Command Semantics 


As specified in [RFC959], the REIN command returns the state of the 
connection to what it was immediately after the transport connection 
was opened. This specification makes no changes to that behavior. 
The effect of a HOST command MUST be reset if a REIN command is 
performed, and a new HOST command MUST be issued afterwards in order 
to connect to a virtual host. 
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3.2.2. User-PI Usage of HOST 


A user-PI MUST send the HOST command after opening the transport 
connection, or after any REIN command, before attempting to 
authenticate the user with the USER command. The following example 
illustrates what a typical login sequence might look like when the 
HOST command is used: 


C> HOST ftp.example.com 
S> 220 Host accepted 

C> USER foo 

S> 331 Password required 
C> PASS bar 

S> 230 User logged in 


If a user-PI sends an additional HOST command before attempting to 
authenticate the user, a server-FTP process MUST treat the additional 
HOST command as though a previous HOST command was not sent and 
return the appropriate reply for the new HOST command. For example, 
if a user specifies the wrong virtual hostname by mistake, sending a 
subsequent HOST command will rectify the error. The following 
example illustrates what the login sequence might look like when the 
HOST command is sent twice before a user has been authenticated: 


C> HOST foo.example.com 
S> 220 Host accepted 

C> HOST bar.example.com 
S> 220 Host accepted 

C> USER foo 

S> 331 Password required 
C> PASS bar 

S> 230 User logged in 


The HOST command can be used in combination with the ACCT command to 
differentiate between a user’s various accounts on a specific virtual 
host. In this scenario, the user-PI sends a HOST command, which the 
server-PI uses to route activity to the correct virtual host; the 
user-PI sends credentials using the USER and PASS commands, which the 
server-PI validates; then, the user-PI sends an ACCT command to 
specify any additional account information for the server-PI 
implementation. The following example illustrates a sequential 
series of client commands that specify both a HOST and ACCT, with the 
server responses omitted for brevity: 


C> HOST ftp.example.com 
C> USER foo 

C> PASS bar 

C> ACCT projectl 
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This is also true when the HOST command is used with the AUTH and 
ADAT commands that are discussed in [RFC2228] and [RFC4217]. In this 
scenario, the user-PI sends a HOST command, which the server-PI uses 
to route activity to the correct virtual host; then, the user-PI uses 
the AUTH and ADAT commands to negotiate the security mechanism and 
relevant authentication token(s) with the server-PI; then, the 
user-PI sends user credentials using the USER and PASS commands, 
which the server-PI validates, after which the user-PI MAY send an 
ACCT command to specify any additional account information for the 
server-PI implementation. The following example illustrates a 
sequential series of client commands that specify both HOST and ACCT 
commands when used in conjunction with the security commands that are 
discussed in [RFC2228] and [RFC4217], with the server responses 
omitted for brevity: 


C> HOST ftp.example.com 
C> AUTH <mechanism-—name> 
C> ADAT <base64data> 

C> USER foo 

C> PASS bar 

C> ACCT projectl 


An exception to the above scenario would be when a user-PI is 
providing the hostname in the "server_name" extension of a Transport 
Layer Security (TLS) extended client hello as discussed in [RFC6066]. 
When the user-PI specifies the hostname in the "server_name" 
extension of a TLS extended client hello, the server-PI MUST verify 
that the hostname in the HOST command matches the value of the 
"server_name" extension. The following example illustrates a 
sequential series of client commands that specify the HOST command 
when used in conjunction with the TLS extensions that are discussed 
in [RFC6066], with the server responses omitted for brevity: 


C> AUTH TLS 
C> HOST ftp.example.com 
C> USER foo 
C> PASS bar 


Additional security information about using the HOST command with the 


security extensions that are discussed in [RFC2228], [RFC4217], and 
[RFC6066] is provided in Section 4 of this document. 
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3.2.3. State Diagrams 


The state diagrams in this section illustrate typical sequences for 
command and reply interchange between the user-PI and server-PI. 
These diagrams are modeled on the similar diagrams in Section 6 of 
[RFC959]. 


In each diagram, the (B) "begin" state is assumed to occur after the 
transport connection has opened or after a REIN command has 
succeeded. Other commands (such as FEAT [RFC2389]) that require no 
authentication may have intervened. 


Additionally, a three-digit reply indicates a precise server reply 
code. A single digit on a reply path indicates any server reply that 
begins with that digit, except where a precise server reply code is 
defined on another path. For example, a single digit "5" will apply 
to "500", "501", "502", etc., when those reply codes are not 
expressly defined in the diagram. For each command, there are three 
possible outcomes: success (S), failure (F), or error (E). In the 
state diagrams below, we use the symbol "B" for "begin" and the 
symbol "W" for "wait for reply". 


For each of these diagrams, without any state transitions being 


shown, a REIN command will return the diagram from any wait state to 
the (B) "begin" state. 
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The state diagram in Figure 1 shows a typical sequence of flow of 
control when HOST is used with USER and PASS to log in toa 
particular FTP virtual host. 


== HOST te= 1753735 
| B |---------- >| w |----------------- 
+---+ 4+---+ | 
| | | 
2,500,502 | | 4,501,503,504 | 
| | Vv 
v 1 | +---+ 
+---+ USER +---+-------------—- >| E | 
| |---------- >| w | 2 | +---+ 
+---+ +---+------- | 2 
stlas || 
A a. Sees | | | 
| i | 
| 1| Wiad 
Vv fof eee == >+---+ 
+---+ PASS +---+ 2 | |s| 
| | ---------- >| w |-------------- >4+---+4+ 
+--+ 4+---+ | | 
| | | 
[4,5 | | 
| --->+--—--+ 
painiin >| F | 
OE REE >+---+ 


Figure 1: Typical Login Sequence with HOST Command 
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After a user has logged in, an additional account may be required by 
the server and specified by the client by using the ACCT command. 
With this in mind, the state diagram in Figure 2 shows a typical 
sequence of flow of control when HOST is used with USER and PASS to 
log in to an FTP virtual host and ACCT is used to specify an account. 


+--—+ HOST tsap 1735-9 
| B |---------- >| w |----------------- 
+---+ +---+ 
2,5007502 | | 4,7501,503;,504 | 
SSeS Be ee ey A ee ea | 
| | | 
v 1 | v 
Pr USER G a e SSeS SSS eee eae 
| [---------- >l wf 2 0 ae >| E | 
+---+ +---+------ | --->+---+ 
|] Ea 
3] ] 4,5 |] | | 
sr eror ES “Seo E Eag 
| (aaa 
my 
| 1| ie (ee 
v | | of | 
+---+ PASS pass 2 | sR >+---+ 
| [-----=---- 1 a >| s | 
+---+ +---+  ----------- >+---+ 
iae aM |] 
3 | 4,5] | E 
| iW ell al | 
| ae oe N | 
1,3| pal al 
v | 2f | v 
+---+ ACCT +---+-- |  ----—- >+---+ 
die P| ways ene >| E| 
+---+ +---+-------------—- >+---+ 


Figure 2: Login Sequence with HOST and ACCT Commands 


The state diagram in Figure 3 shows a typical sequence of flow of 
control when HOST is used with the AUTH and ADAT commands that are 
discussed in [RFC2228]. (NOTE: Section 4 provides additional 
information about using the HOST command with TLS.) 
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+--—+ HOST fee St dy 375 
| B |---------- >| w |------------------ 
+---+ +---+ 
| | | 
2,500,502 | | 4,501,503,504 | 
Darna na IT A sv Dera eed ig ete | 
| | | 
v Mog 
+---+ AUTH +---+ 4,5 
M A aaa > | 
+--+ +--+ | | 
334 |] | 
See nae | 
| 234 | | | 
J nanan } | 
V 4,5 
+---+ | ADAT +---+----------- > 
|. (s725 >| w | 335 | | 
+---+ | +---+----- | | 
a fi | | | | 
eee | | | | 
| i P| 
---- 235 | | | 
ME ci race | | 
| | | v 
Vvv 1 | +---+ 
+---+ USER 4+---4--------------- >| E | 
| [Rss >| w | 2 by eae 
+--+ +---+------- | x 
| | | | | 
3 | | 4,5 | | | 
seaGsGeaenerss) «Petar | | | 
| | | | 
| | | | | 
V | ------- >+---+ 
+---+ PASS +---+ 2 | | |s| 
| |---------- >| w |--------------- >+---+ 
+---+ +---+ 
| 
[4,5 | | 
| | -->+---+ 
ime, >| | 
----------------- >+---+ 


Figure 3: Login Sequence with HOST and AUTH/ADAT Commands 
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After a user has logged in with the security commands that are 
discussed in [RFC2228], an additional account may be required by the 
server and specified by the client by using the ACCT command. The 
state diagram in Figure 4 shows a typical sequence of flow of control 
when HOST is used with the AUTH and ADAT commands to log in to an FTP 
virtual host and ACCT is used to specify an account. 


+--—+ HOST $a —= + 1737.9 

| B |---------- >| w |------------------ 
+---+ +---+ | 
| | | 
2,500,502 | | 4,501,503,504 | 
+-------------- -------------- | 
| | | 
v | | 
+---+ AUTH +---+ 4,5 | 

I aa 2 Ai Ree aor > 
4+---+ +--+ | | 
334 | | | | 
| 234 | | | 
Vv | 4,5 | | 

+---+ | ADAT $---4------------ > | 
WIS aoe as >| w | 335 | | 
+---+ | 4---4----- | | 
SAR | | | | 
ke i | | | | 
| | | | 
---- 235| | | 
|, oe | | 
| | | | 
Vv vV 1 | V 
+---+ USER 4---4--------------- >+---+ 
J [aa alw 2 a >| | 
pneg 4---4------- | --->+---+ 

| | Tie 

3 | | 4,5 | | 

| ing. 

|) - |“ eGdeScesses | | 

| 1| be. Wh 

Vv | Fa E 
4+---+ PASS +---+ 2 | ------- >+---+ 
[I sss >| Wh | pesasesoseseees >| s | 
+--+ f---$ 9 ------------ >+---+ 
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cr 


3; 


3 | lesi | | | 
La. Ut Al 
| 1,3| PER | 
v ee ee i v 
+---+ ACCT +---+-- | ------ >+---+ 
— >| w | 4,5 --------- >| F | 
+---+ 4+---4--------------- >+---+ 


Figure 4: Login Sequence with HOST and AUTH/ADAT/ACCT Commands 
HOST Command Errors 


The server-PI SHOULD return a 500 or 502 reply if the HOST command is 
unrecognized or unimplemented, as specified in [RFC959]. For 
example, a server-PI that predates or otherwise does not conform to 
this specification would be expected to return a 500 or 502 reply. 


As discussed in Section 3 of this document, if a HOST command is sent 
after a user has been authenticated, the server MUST treat the 
situation as an invalid sequence of commands and return a 503 reply. 


A 501 reply SHOULD be sent if the hostname given is syntactically 
invalid, and a 504 reply SHOULD be sent if a syntactically valid 
hostname is not a valid virtual hostname for the server. In all such 
cases, the server-FTP process MUST do one of the following: 


a. Ignore the HOST command and act as if a HOST command had not been 
sent. A user-FTP process MAY then send a subsequent HOST command 
with a different hostname. 


b. Close the connection. 


A user-PI receiving a 500 or 502 reply to a HOST command SHOULD 
assume that the server-PI does not implement virtual servers by using 
the HOST command. The user-PI MAY then proceed to log in as if the 
HOST command had not been sent. 


A user-PI receiving an error reply that is different from the errors 
that have been described here SHOULD assume that the virtual HOST is 
unavailable and terminate communications. 


A server-PI that receives a USER command to begin the authentication 
sequence without having received a HOST command SHOULD NOT reject the 
USER command. Clients that conform to earlier FTP specifications do 
not send HOST commands. In this case, the server MAY act as if some 
default virtual host had been explicitly selected, or the server MAY 
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enter an environment that is different from that of any supported 
virtual hosts, perhaps one in which a union of all available accounts 
exists and that presents an NVFS that appears to contain 
subdirectories that contain the NVFS for all supported virtual hosts. 


3.4. FEAT Response for HOST Command 


When replying to the FEAT command [RFC2389], a server-FTP process 
that supports the HOST command MUST include a line containing the 
single word "HOST". This word is case insensitive, but it SHOULD be 
sent in upper case so as to maximize interoperability with disparate 
implementations. That is, the response SHOULD be: 


C> FEAT 

S> 211- <any descriptive text> 
S> ays 
S> HOST 
Sor ~<a ses 

S> 211 End 


The ellipses indicate placeholders where other features may be 
included but are not required. The one-space indentation of the 
feature lines is mandatory [RFC2389]. 


4. Security Considerations 


As discussed in Section 3 of this document, a server implementation 
MUST treat an additional HOST command that was sent before a user has 
been authenticated as though a previous HOST command was not sent. 

In this situation, the server implementation MUST reset the 
authentication environment, as that would allow for segregation 
between the security environments for each virtual host on an FTP 
server. The implementation details for security environments may 
vary greatly based on the requirements of each server implementation 
and operating system, and those details are outside the scope of the 
protocol itself. For example, a virtual host "foo.example.com" on an 
FTP server might use a specific username and password list, while the 
virtual host "bar.example.com" on the same FTP server might use a 
different username and password list. In such a scenario, resetting 
the security environment is necessary for the virtual servers to 
appear to behave independently from a client perspective, while the 
actual server implementation details are irrelevant at the protocol 
level. 


Section 15.1.1 of [RFC4217] discusses the use of X.509 certificates 
for server authentication. Taking the information from that document 
into account, when securing FTP sessions with the security mechanisms 
that are defined in [RFC4217], client implementations SHOULD verify 
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that the hostname that they specify in the parameter for the HOST 
command matches the identity that is specified in the server’s X.509 
certificate in order to prevent man-in-the-middle attacks. 


When the HOST command is used in combination with the FTP security 
extensions that were introduced in [RFC2228] and [RFC4217], the HOST 
command SHOULD precede the security handshake when the user-PI is not 
providing the "server_name" in the extended client hello as defined 


in [RFC6066]. This allows both user-FTP and server-FTP processes to 
map an FTP HOST with the correct server name in the server’s 
certificate. If the HOST command is sent after the security 


handshake, then mapping an FTP HOST to the correct security 
certificate will not take place before the secure session is 
established. 


For example, if a server-FTP process has multiple virtual hosts 
defined and no hostname has been sent from a user-FTP process, the 
server-FTP process will be unable to route the connection to the 
correct virtual host when the connection is established. In this 
situation, the server-FTP process will be forced to choose a virtual 
host that will respond. When the user-PI attempts to negotiate a 
secure connection, the virtual host to which the connection was 
routed will respond with its server certificate during the security 
handshake. If the virtual host that was chosen by the server-FTP 
process does not match the virtual host to which the user-FTP process 
had intended to connect, the user-PI will be unable to verify the 
server’s identity as presented in the server certificate message. 


However, if the user-PI is providing the "server_name" in the 
extended client hello as defined in Section 3 of [RFC6066], the 
user-PI MAY provide the HOST command after the security handshake 
because the server will be able to route the connection to the 
correct virtual host based on the contents of the "server_name" 
extension and the client will be able to verify the server’s identity 
as presented in the corresponding server certificate message. 
However, the server-PI MUST verify that the name in the HOST command 
matches the "server_name" that is provided in the extended client 
hello. 


In general, client implementations SHOULD protect user credentials by 
using the FTP security extensions that were introduced in [RFC2228] 
and [RFC4217]; a detailed discussion for securing FTP sessions can be 
found in those documents, and a general discussion of security issues 
related to FTP can be found in [RFC2577]. 
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5. IANA Considerations 


IANA has registered the following FTP extension according to the 
procedure established by [RFC5797]: 


+------ +--------- +------------- +------ +------ +---------------------- + 
| cmd | FEAT | description | type | conf | RFC#s/References and | 
| | Code | | | | Notes | 
+------ +--------- +------------- +------ +------ +---------------------- + 
| HOST | HOST | Hostname | a | o | RFC 7151 | 
+------ +--------- +------------- +------ +------ +---------------------- + 
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Appendix A. Unworkable Alternatives 


Due to the level of scope for adding a new command to FTP, a brief 
discussion of suggested alternatives to a HOST command and their 
respective limitations is warranted. The suggested alternatives that 
are discussed in this appendix have been proposed in the past, but 
each of these ideas was deemed insufficient for the reasons listed 
within each section of this appendix. 


A.1. Overloading the CWD Command 


One suggested method to emulate a form of virtual hosts would be for 
the client to simply send a CWD command after connecting, using the 
virtual hostname as the argument to the CWD command. This would 
allow the server-FTP process to implement the file stores of the 
virtual hosts as subdirectories in its NVFS. This suggestion is 
simple in concept, and most server-FTP implementations support this 
without requiring any code changes. While this method is simple to 
describe and implement, it suffers from several drawbacks: 


a. The CWD command is available only after the user-PI has 
authenticated itself to the server-FTP process. Thus, all 
virtual hosts would be required to share a common authentication 
scheme if they used this method. 


b. To make the virtual host truly transparent, either the server-FTP 
process needs to be modified to include information that shows 
the special nature of this first CWD command (negating most of 
the advantage of this scheme), or all users must see the same 
identical NVFS view upon connecting (they must connect in the 
same initial directory), or the NVFS must implement the full set 
of virtual host directories at each possible initial directory 
for any possible user. 


c. Unless the server is specially modified, a user connecting this 
way to a virtual host would be able to easily move to any other 
virtual host supported at the same server-FTP process, exposing 
the nature of the virtual host. 


A.2. Overloading the ACCT Command 


Another suggested method would be to simply overload the ACCT command 
for FTP virtual hosts, but this proposal is unacceptable for several 
reasons with regard to when the ACCT command is sent during the 
request flow. Sections 5.4 and 6 of [RFC959] document the request 
flow for a login sequence as USER -> PASS -> ACCT. This flow of 
commands may be acceptable when you are considering a single user 
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having multiple accounts on an FTP server, but it fails to 
differentiate between virtual hosts when you consider the following 
two issues: 


a. The first problem with overloading the ACCT command is 
certificate negotiation when using the FTP security extensions 
that are documented in [RFC2228] and [RFC4217]. In order to 
safeguard user credentials, negotiation of the security mechanism 
and certificate must occur before login credentials are sent by 
the client. The problem with using the ACCT command in this 
scenario is that there is no way of ensuring that the certificate 
matches the correct virtual host before the user credentials are 
sent. 


b. The second problem with overloading the ACCT command is how user 
credentials are implemented for FTP virtual hosts. FTP server 
implementations may allow the use of custom user credentials on a 
per-virtual-host basis. For example, in one particular 
implementation the virtual host negotiation occurs, and then the 
user credentials are looked up using the account mechanism that 
is specific to that virtual host. So once again the virtual host 
negotiation must take place before the user credentials are sent. 


A.3. Overloading the USER Command 


An additional suggestion would be to overload well-known syntax 
through the existing USER command, as illustrated in the following 
example: 


C> USER foo@example.com 
S> 331 Password required 
C> PASS bar 

S> 230 User logged in 


In this example, the user "foo" might be attempting to log on to the 
virtual host "example.com" on an FTP server. This suggestion may 
seem plausible at first, but it introduces several implementation 
problems. For example: 


a. Some network environments already use the "username@hostname" 
syntax for network credentials, where the "hostname" portion 
refers to the location of the user’s credentials within the 
network hierarchy. Using the "foo@example.com" syntax, it 
becomes difficult to differentiate between the user "foo" logging 
into a virtual host that is named "example.com" on an FTP server 
versus the user "foo@example.com" logging into an FTP server with 
no specified virtual host. 
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b. When using the FTP security extensions that are documented in 
[RFC2228] and [RFC4217], negotiation of the security mechanism 
and certificate must occur before login credentials are sent by 
the client. More specifically, the AUTH/ADAT commands must be 
sent before the USER command in order to safeguard user 
credentials. If you overload the USER command, there is no way 
of ensuring that the certificate matches the correct virtual host 
before the user credentials are sent by the client. 


A.4. Conclusion 


After examining the above alternatives, and in order to obtain an 
adequate emulation of "real" FTP servers, it was concluded that 
supporting virtual hosts will require both client and server 
modifications. Therefore, a new FTP command seems the most likely 
solution to provide the required level of support. 
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